home *** CD-ROM | disk | FTP | other *** search
/ The CDPD Public Domain Collection for CDTV 4 / CDPD_IV.bin / e / mailinglists / amigae.0793july.archive / 000117_crash!mars.let.uva.nl!wouter_Fri, 30 Jul 93 21:43:54 PST.msg < prev    next >
Internet Message Format  |  1994-05-26  |  5KB
  1. Received: by bkhouse.cts.com (V1.16/Amiga)
  2.     id AA00000; Fri, 30 Jul 93 21:43:54 PST
  3. Received: from mars.let.uva.nl by crash.cts.com with smtp
  4.     (Smail3.1.28.1 #15) id m0oM7KT-0000EEC; Fri, 30 Jul 93 20:09 PDT
  5. Received: by mars.let.uva.nl id AA14651
  6.   (5.65c/IDA-1.4.4 for amigae@bkhouse.cts.com); Sat, 31 Jul 1993 05:13:42 +0200
  7. Return-Path: <wouter@mars.let.uva.nl>
  8. Date: Sat, 31 Jul 1993 05:13:42 +0200
  9. Message-Id: <199307310313.AA14651@mars.let.uva.nl>
  10. X-Organisation: Department of Computational Linguistics,
  11.                 University of Amsterdam
  12.                 Spuistraat 134, 1012 VB Amsterdam, The Netherlands
  13. From: Wouter van Oortmerssen <wouter@mars.let.uva.nl>
  14. To: amigae@bkhouse.cts.com
  15. Subject: wishes, objects, and modules
  16.  
  17. >> Here's my list of things I would like to have when I'm
  18. >> programming in E:
  19. >> 
  20. >> MAJOR
  21. >> 
  22. >> * Object Oriented support (already planned anyway, I think)
  23.  
  24. with v2.5, you'll have object inheritance, with more on the way.
  25.  
  26. >> * Ability to break code into units like Pascal
  27.  
  28. is in v2.5. the system resembles very closely the "units" of turbopascal.
  29.  
  30. >> * Ability to include files for graphics/sound at the
  31. >>   command line
  32.  
  33. um, you mean the chip thing you're all screaming for?
  34. I'll _think_ about it :-)
  35.  
  36. >> * Proper object support, so I can use
  37. >>   window.userport.sigbit
  38.  
  39. E's concept for OBJECTs is simply different from how most people
  40. are used to program. I've indeed seen that this can be somewhat
  41. of a nuisance, and I'd like to provide better, but it isn't
  42. going to be simple (imagine, it also involves also ALL modules to
  43. be radically rewritten, for a start.).
  44.  
  45. >> MINOR
  46. >> 
  47. >> * Some way of specifying more than one variable of a given
  48. >>   type, e.g. instead of A:INT,B:INT,C:INT use A;B;C:INT
  49.  
  50. don't count on it.
  51.  
  52. >> * Some way of saving register values for programming hooks
  53.  
  54. v2.5 provides an installhook() function that does all the dirty
  55. work for you.
  56.  
  57. >> * Don't know if there's a reason for this, but some E
  58. >>   module object names appear to be different, e.g. mp
  59. >>   instead of msgport, sigbit instead of mp_sigbit
  60.  
  61. they're different because commodore made the C and Assembly
  62. names different, and E uses the Assembly ones. Commodore
  63. also prefixed the names in assembly (and later some in C too),
  64. because in assembly such a label has no type, but in E this
  65. is superfluous, since the pointer that it is used with, has a type.
  66. simply remember, if a name in Asm or C has a prefix, it won't have
  67. one in E.
  68.  
  69. >> Remember, these are just suggestions
  70. >> 
  71. >> Dave.
  72.  
  73. --
  74.  
  75. >> I agree, E will have a better reputation in the Amiga community
  76. >> if it is 100% standardized with C='s includes...
  77. >> 
  78. >> Alan
  79.  
  80. remember that E's includes already resemble those of C and Asm
  81. quite closely (have you ever seen the names (and the directory structure)
  82. of the includes that come with some modula2 and Oberon compilers?).
  83.  
  84. --
  85.  
  86. >> > * Object Oriented support (already planned anyway, I think)
  87. >> 
  88. >> > * Proper object support, so I can use
  89. >> >   window.userport.sigbit
  90. >> 
  91. >> Object-orientedness was in from the first release, its just not
  92. >> working right yet (right, Wouter?).
  93.  
  94. indeed. the E language has been OO just about from the beginning
  95. (2 years ago), but my compiler-writing skills advanced slower than my
  96. language designing skills :-)
  97.  
  98. >> I definately want to see proper object support like above.
  99.  
  100. me too.
  101.  
  102. >> But lets not forget to thank Wouter for a wonderful language!
  103.  
  104. you will be enjoying it even more now more of it gets implemented.
  105.  
  106. >>    Chad Freeman
  107.  
  108. --
  109.  
  110. >> I mentioned the "mp" case specifically because it caused
  111. >> me problems. Now I know about it, I can avoid that problem
  112. >> in the future, but how many other differences are there?
  113.  
  114. in Assembly, it's also called "mp" (or "MP", to be precise).
  115. When looking through includes, take the assembly ones instead
  116. of the C ones, which will be the same as the E ones (strip
  117. off the prefix).
  118.  
  119. --
  120.  
  121. >> Once you become accustomed to the modules' naming conventions it's not difficult
  122. >> 
  123. >> to use the RKRMs to locate components in the modules.  What about all the code
  124. >> already written against E's current modules?  I myself would not look forward to
  125. >> converting a project the size of my EPP program (or larger!) if Wouter changes
  126. >> the existing component names. 
  127.  
  128. I won't, for that reason.
  129.  
  130. >> Anyway, I think mp_sigbit is redundant since the
  131. >> component belongs to an mp object.  I'm convinced Commodore set that convention
  132. >> because of C programmers' infamous tendency to use such descriptive variable
  133. >> names as "a" and "x".  :-)
  134.  
  135. :-)
  136.  
  137. -- Barry
  138.  
  139.  
  140. Wouter
  141.  
  142.    ____  Wouter van Oortmerssen, Wouter@alf.let.uva.nl
  143.   / __/  "Einen Satz verstehen, heisst, wissen was der Fall ist,
  144.  / __/    wenn er wahr ist" - Wittgenstein
  145. /___/  ->subscribe to the E mailing list: amigae-request@bkhouse.cts.com<-